ty for PR!
looks fine, but stuck in architectural deadlock here

issue is:
if cvar check stays inside HintMessageEx (like right now), it breaks rg_hint_message native for custom plugins
but if moving check outside directly to game code, it breaks RG_CBasePlayer_HintMessageEx hook for plugins that need to catch vanilla events
so no clean way to fix this on engine side without breaking ReAPI for someone

i am not sure, but maybe better to shift this responsibility to plugins
since impossible to solve all cases here, doing it via 3rd-party is much more flexible

ty for PR! looks fine, but stuck in architectural deadlock here

issue is: if cvar check stays inside HintMessageEx (like right now), it breaks rg_hint_message native for custom plugins but if moving check outside directly to game code, it breaks RG_CBasePlayer_HintMessageEx hook for plugins that need to catch vanilla events so no clean way to fix this on engine side without breaking ReAPI for someone

i am not sure, but maybe better to shift this responsibility to plugins since impossible to solve all cases here, doing it via 3rd-party is much more flexible

Thanks for the detailed breakdown — you're right that there's no clean way to do vanilla-only suppression on the gamedll side. Both vanilla and plugin hints funnel through the same CBasePlayer::HintMessageEx, so there's no origin signal to key on, and gating at the call sites would hide vanilla events from RG_CBasePlayer_HintMessageEx hooks.

I've reframed the change rather than trying to solve the unsolvable case. The cvar is now positioned as a master kill-switch, not a vanilla-only filter:

• Default 1 — zero behavior change, vanilla builds untouched.
• 0 — suppresses non-forced hints server-side. The check sits in the HintMessageEx OrigFunc (chain terminal), so plugin hooks still fire and can observe every event.
• bOverride bypasses it, exactly as it already bypasses the per-client m_bShowHints (_ah) preference. So it doesn't introduce a new failure mode — non-override hints were already suppressible per client — but I'll be honest that it does widen the scope: with the cvar off, non-override
• rg_hint_message calls are dropped for all clients, so a plugin that needs guaranteed delivery must pass override.

I fully agree this doesn't cover every case, and forcing a hint against the server's wishes is reasonably a plugin's responsibility. So I'm leaving the call to you (@s1lentq) — if you feel this doesn't belong in the core and is better left to third-party plugins, please go ahead and close the PR. No hard feelings at all.